I wrote this cdev mainly because I was tired of having to (a) browse through my System Folder looking at file names or (b) use ResEdit on the QuickTime init, just to see what the heck kinds of things (er, excuse me, components) I had lying around my system. Anyway, this first version of Things! mainly just queries the Component Manager about what IT thinks is lying around your system, and then displays the info for you.
Things! will not show up in your Control Panel (or alternatively, will not launch under System 7) if (a) the Gestalt call is not available (meaning you're running a fairly old system), (b) the Component Manager is not installed, or (c) the Component Manager version is not recent enough (you shouldn't hit this one for a while - the Component Manager has been at version 1 for quite some time).
Note of interest: Things! can only find components that are (a) registered globally or (b) are registered in its A5 world. It won't find components that are registered locally to A5 worlds other than the one it lives in (yet). Also, if you edit a component that is in the same A5 world that the Things! cdev lives in, Things! will register this component back globally, whether it was originally registered that way or not. I don't currently have a way to tell whether or not a component is registered locally or globally, so I assume if I can see it, it must be global.
This cdev is mainly intended as a utility (read that, hack) for QuickTime developers, although I've been told it's mildly interesting to non-engineering types, too - it never hurts to be aware of what's going on in your system!
--------------------------------
Minimum required configuration:
Component Manager version 1
System 6.0.7 or later
--------------------------------
Tested configurations:
Mac IIfx, 32 Mb RAM (?!), running 6.0.7 and QuickTime 1.0b9
Mac IIfx, 32 Mb RAM (?!), running 7.0 and QuickTime 1.0b9
Mac IIci, 8 Mb RAM, running 7.0 and QuickTime 1.0b9
Mac II, 8 Mb RAM, running 7.0 and QuickTime 1.0b9
--------------------------------
Known bugs:
1.0d1
- The cdev occasionally bus-errored if you clicked back and forth between two components in the name list long enough. I think this was due to a bad memory dereference (handle wasn't locked), and should be fixed in 1.0d2.
1.0d2/1.0d2+
- The type list occasionally loses some types after a "Destroy" or a name or info edit (sometimes this is OK, for example, if you just destroyed the last component of a given type). Just close the cdev and re-enter it and everything should be jake. I'm working on finding out what's going on with this.
- When Things! is in the background, and components are registered/unregistered, sometimes it gets confused (this is definitely MY fault - I need some additional checks on my lists). Same story as above; just leave and re-enter and stuff is OK.
- Back to back edits on the same field (name or info) on the same component usually screws up the name list. Same story as above; just leave and re-enter and stuff is OK.
- Using cut/paste/copy/clear command keys appends the key character (for example, "X" for Cut) in the text edit field. Using the menu for these commands works fine.
- Some crashes have been seen while using Things! under System 6.0.x - I haven't had time to track these down yet.
--------------------------------
Version history:
1.0d1 6/10/91
- First release
1.0d2 7/28/91
- Changed cdev so that it will update its information on update or idle events (it checks the component list mod seed to see if this is necessary). This allows the cdev to pick up registrations/unregistrations of components that occur while it is not the active window (sort of like a component monitor). This is sorta working.
- Changed name list to highlight the default component for the selected type when the name list is drawn.
- Name field can now be edited by option-clicking on it. Cut, copy, paste, and clear are supported, but undo is not yet implemented, so BE CAREFUL. A note: If the component does not have a 'thng' resource, or if there are currently instances of the component, editing will not be enabled (big surprise). Editing is terminated by clicking anywhere outside the edit box, or by hitting the return or enter keys.
- Put in paging code; the cdev now has a number of "pages" on the bottom third of the display. Paging is controlled by the left and right arrow buttons at the top left of this area, or by using the left and right arrow keys on the keyboard. The various pages are described below.
Page one: Displays the component info. Option-clicking on this field will allow standard text editing, including cut, copy, paste, and clear. Editing is terminated by clicking anywhere outside the edit box, or by hitting the return or enter keys. Note that undo has NOT been implemented yet, so BE CAREFUL. A note: If the component does not have a 'thng' resource, or if there are currently instances of the component, editing will not be enabled (big surprise again).
Page two: Displays the component's implementation version and interface version, along with a button ("Set default") to make the currently selected component the default component for that type (unfortunately, this selection doesn't currently get remembered across restarts). If this page was entered with the option key held down, then a second button will be available ("Destroy"); this button allows you to UNCONDITIONALLY unregister a component. BIG WARNING: THIS IS NOT UNDOABLE, except by re-registering the component (this is ordinarily done at startup through auto-registration, although if the component was programmatically created, my guess is you would have to re-launch your app). I would advise you NOT to futz with this control unless you really know what you're doing with respect to components and the Component Manager. If an application that you're currently running is using an instance of the component that you decide to nuke with this control, that application will AT LEAST start issuing all sorts of error alerts/messages, or AT WORST just exhibit extremely unpredictable behavior (including but not limited to crashes). This will happen because when you nuked the component, the application using it generally isn't aware that the component (and its accompanying instance) is no longer valid as far as the Component Manager is concerned; thus, Component Manager calls to this component or ANY calls to its instance will return errors, and what happens next sorta depends on how robust the application's error checking is. Now, you're probably wondering, if this control is so NASTY, why even have it around? Well, it turns out to be fairly useful in the development and test of new components; it is NOT intended for casual use. 'Nuff said.
Page three: Displays the state of the component flags and flags mask of the currently selected component. For now, I've got some really cumbersome left/right arrows that let you select the flag you're interested in - I'll get rid of these buttons in favor of something more direct shortly. A description of the currently selected flag (if available) is displayed at the bottom of the page. Point of interest: The flags mask, as defined in the component resource, should be all clear (no bits set). If a bit is set in the mask, you've probably goofed up somewhere (or, alternatively, I've got a weird bug in this cdev...). Also, the flags draw pretty slowly right now - this'll get fixed soon. If the currently selected component doesn't have a 'thng' resource, then I've got no idea what the flags are (since I don't have a 'thng' resource to look at), so basically, you don't see any flags or mask.
Page four: Displays the resource info and attributes of the currently selected component. If the component has no 'thng' resource, you get a bunch of blank spaces.
Page five: Displays version info for the System Software, the Component Manager, QuickTime, and the Compression Manager. If you have only installed portions of the above (for example, you're using the Component Manager init, but not the Movies Toolbox or Compression Manager inits), you should only see version info for the stuff that is installed.
Page six: About box.
- Put in code to show the number of instances of a given type of component and the number of instances of a given component (clicking on the text toggles between the two displays).
- Fixed miscellaneous obscure memory bugs (I hope).
- Put in a System 7 style control panel ICN# resource.
- Added Finder help balloon; others to come as soon as I get around to it.
1.0d2+ 9/1/91
- No functional changes, just added a few more component OSTypes to the thtp resource to
keep up to date with the latest QuickTime init.
--------------------------------
Some details about strings:
I've come up with three new component resource types: 'thsf', 'thdf', and 'thtp'. At present, all occurences of these resources exist in the Things! cdev. The 'thsf' resource maps strings to each of the bits in the high byte of the component flags (for example, bit 31 maps to the string "Call this component during startup"). The meaning of these bits is strictly determined by Apple. The 'thdf' resource maps strings to each of the bits in the lower three bytes of the component flags. The meaning of these bits is determined by the component developer. In the Things! cdev there are, among others, a default 'thdf' resource which lists each of the flags as "Undefined", one for image compressors/decompressors, and one for 'clok' components. The 'thtp' resource maps strings to component OSTypes (for example, 'appl' maps to the string "Apple Computer, Inc.").
Ideally, it would be nice to have the 'thsf' resource and basic (or known) 'thdf' and 'thtp' resources incorporated into the QuickTime init, and for each component to carry with it its own 'thdf' and 'thtp' resources. This way, applications could search for strings first in the component itself, and then, if no match is found, in the QuickTime file.
A complication with this scheme that has not been adequately addressed at this time concerns internationalization of the strings.
None of this has been officially adopted yet, so don't go wild worrying about putting it into your components.
If you're curious about this stuff, I've included a ResEdit file with the templates for the resources discussed above, and you can use the templates to go look at these resources in the Things! file. (Sorry, no class on using ResEdit templates here - go look in the ResEdit reference for info on installing them in your system).
--------------------------------
Assumptions:
I assume that the resourceSpecs for the name and info for all components describe Pascal style strings (e.g. 'STR ' , 'STR#', 'TEXT', or make up your own type), and that the resourceSpec for icons are of some normal icon resource type ('ICON', or 'ICN#', for now, possibly 'cicn' and others in the future).
A caveat with respect to editing: It is remotely possible that when you ask Things! to edit the 'thng' resource of a component, it might find the wrong one. Things! goes through a lengthy matching process to find the right component resource for a given component; there is no call in the Component Manager which will return you a component's resource file for write access. [Aside: Before anyone starts griping about this, life is this way because having write access to the component's resources means you can change stuff behind the Component Manager's back, and, in fact, behind the back of any app that's using that component, and serious nasties can subsequently occur. That's why most folks get to play with INSTANCES of a component, rather than the component itself; the component is the pure and pristine template for all its instances, and we wouldn't want to dirty it up by munging it.] Anyway, Things! may make a bad match ONLY if you happen to have two components in the same file with contents of their ComponentResources matching EXACTLY. In other words, the following must match:
- name resource type
- name resource ID
- name
- info resource type
- info resource ID
- info
- icon resource type
- icon resource ID
- icon
- code resource type
- code resource ID
- type
- subtype
- manufacturer
Unless you really go out of your way to do this, it's a pretty unlikely situation. The only situation I've been able to dream up where this MIGHT happen is if you were upgrading a component in a file via some kind of script (like via Installer) and it didn't delete the old component from the file. So, anyway, I'm assuming that no one is going to construct this situation, and life will be jolly. Just thought I'd mention it.
--------------------------------
Miscellaneous:
- If a component does not have any resources for name or information, or they provide resources which are empty, I just put up "Untitled component", "(None)" or somesuch meaningless string.
- Some components do not appear to be supporting the application-level GetComponentVersion call (that is, they are returning error codes like paramErr, if they return anything decipherable at all).
